iT邦幫忙

2024 iThome 鐵人賽

DAY 2
0
DevOps

從 AWS 轉生到 GCP 世界,還順便轉職成 DevOps 的 SRE系列 第 2

Day 2 前世帶來的經驗大大改善了今生的順暢度,GCP Storage Signed URL(AWS S3)

  • 分享至 

  • xImage
  •  

前情提要

我們有個需求是要將資料上傳到 Storage,原本的流程是先到 Cloud Run(AWS 的 ECS) 再轉丟到 Cloud Storage,但 Cloud Run 的 Bandwidth limits 有限制,所以後來改將服務掛到 GKE 上,改用 GKE 上傳。

https://ithelp.ithome.com.tw/upload/images/20240916/20118525kK9hCLG6dX.png

討論及思考

在現有的架構上,因為走 GKE 要先經過 ALB → GKE → S3,多了 ALB 的費用,以及 GKE 要維護的 Effort,非常不人道。事先確認了一下是否在 GKE 上需要做類似 Data 預處理的 Features,確認沒有。所以提出了改用 Storage Signed URL 的方式(S3 也有)。直接從用戶端發送給 Storage,我們只需確認是否要發這個 URL 給用戶就好。

signed URL 的特點是你產生出來的時間可以自己自定義(最長7天),然後他可以限制 Read or Write 權限。改成走這條路後,我們可以很輕鬆地省掉兩件事

  1. 監控是否用戶上傳有掉包或是上傳導致 instance 過載

  2. 節省費用,包含 NEtwork 以及 GKE 的維護


上一篇
Day1 睜開眼轉生到異世界要先做啥
下一篇
Day3 兩個 Cloud Run 內部溝通
系列文
從 AWS 轉生到 GCP 世界,還順便轉職成 DevOps 的 SRE30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言